IBIS Macromodel Task Group

Meeting date: 01 October 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Altair:                     * Junesang Lee
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:              * Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                            * Jared James
Dassault Systemes:            Longfei Bai
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              [Kinger Cai]
                              Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
                              Sai Zhou
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:               * Chulsoon Hwang
                            * Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Samsung:                      Jun-Bae Kim
Siemens EDA (Mentor):       * Arpad Muranyi
                            * Randy Wolff
Signal Edge Solutions         Benjamin Dannan
Teraspeed Labs:               [Bob Ross]
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

Yifan:  Further investigate the feasibility of using the plateau test to decide
        whether BIRD220.1 is applicable for a given device model.
        - Done.  Yifan said she had an update to present.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the September 24th
meeting.  Michael moved to approve the minutes.  Ambrish seconded the motion.
There were no objections.

--------------
New Discussion:

BIRD220.1 update:
Yifan reported on her continued investigation into whether looking for plateaus
in the rising/falling edges of output transitions is a suitable test for the
validity of the BIRD220.1 approach.  She had previously demonstrated that the
presence of a plateau in the edge when driving into a V_fixture of Vdd/2 was
sufficient to indicate that BIRD220.1 was not applicable to the device, as it
indicated the presence of separate pre-drivers for the pullup and pulldown
stages.  She then turned to determining whether the absence of the plateaus was
sufficient to indicate that BIRD220.1 was applicable.

Yifan showed a demo driver model including separate pre-driver stages.  She had
tuned the sizes of the NAND and NOR gates so that no plateau was seen when
driving 50 Ohms to V_fixture = 0.  She then swept V_fixture and demonstrated
that no plateaus were seen in any of the rising edges.  However, when she
introduced noise on the pre-driver power rail, the PSIJ values were different
for the pullup and pulldown pre-driver stages, and consequently the PSIJ value
at the output was different than either of them and highly dependent upon the
load.

Yifan concluded that BIRD220.1 could not be applied to a device with separate
pre-driver stages, even if they were synchronized to minimize skew between them.
While a model maker could derive an equivalent PSIJ value for the device into a
particular load, it would likely only be valid for that particular load.  One
possibility would be to provide the associated load along with the PSIJ value,
as the model maker may know what the expected load conditions are.

Arpad asked whether adding a PSIJ subparameter to the rising and falling
waveform keywords would help.  The waveform keywords already contain
subparameters describing the load associated with each waveform.  Yifan agreed
that doing so would provide more information, but she asked how it would be
utilized in simulation if the buffer is not aware of its real-time load.

Arpad said he was wondering whether there was a reliable way for model makers to
know whether BIRD220.1 was valid for their device, and he asked where we should
go from here with this BIRD.  Chulsoon said he and Yifan had discussed the issue
at length.  He suggested that they would proceed with the known limitation that
BIRD220.1 can only be applied to devices with a single common pre-driver stage.
Yifan said she would create a new draft of BIRD220.1 with additional sentences
describing the limitations of the technique.

Ts4file and [Ramp]:
The group continued the previous discussions, and Michael focused on the table
Walter had created enumerating the combinations of I-V, V-t, Ts4file, and
External Model and their interactions with [Ramp] (sent to ATM prior to the
meeting).  Arpad noted that the [Ramp] dV vs. I-V check was missing.  Walter
agreed and said he would add another column.

Walter said [Ramp] is used for time stepping when doing a time domain
simulation, or for a fast crosstalk scan.  He said it is only used to generate
K(t) tables in the case where a model has I-V tables but no V-t waveforms.
The parser currently only checks dV vs. I-V data, if I-V data exists.

Ambrish said that [Ramp] may be syntactically required even when Ts4file is
used, but it is not technically necessary.  He said we should make it clear that
[Ramp]'s only purpose is a first-order estimate of switching behavior in the
Ts4file case.  He suggested we use the same language used in the [External
Model] case.  Walter agreed.

Michael noted that the table indicates where parser cross checks of [Ramp] data
with other keywords' data are missing.  He said the key question remains, what
do we want to do for changing/defining parser requirements for checking [Ramp]
vs. the newer replacement parameters/keywords (Ts4file, External Model)?
Ambrish said the impetus for this whole discussion had been problems Michael
encountered with a Ts4file model, and the parser's confusing checks of [Ramp]
vs. I-V data in that case.  He said the original intention when Ts4file was
introduced was that if Ts4file is in the .ami file, then it replaces (is used
instead of) the legacy modeling information in the .ibs file entirely.  Arpad
said that if we state that Ts4file is for AMI purposes only, then we have to
allow the model to contain information to be used in non-AMI simulations.
Ambrish said you could simply wrap your Touchstone file in a subcircuit and
use [External Model] in that case, as the Ts4file section recommends use of
[External Model] for providing equivalent behavior for non-AMI simulations.
Arpad said one limitation of that approach is that Ts4file 4-port data models
aren't useful for power integrity simulations.

Walter said it's perfectly fine for a tool to use the Ts4file information in a
time domain simulation, and the syntactically required [Ramp] is then useful as
first-order time stepping information.  Ambrish said that this violates the
original spirit of the Ts4file parameter's usage, and if we want to use it for
all simulation types then it should be in the .ibs file, not the .ami file.

Michael said we need to decide if we should continue to require [Ramp] even in
the presence of the new replacement keywords, or if we should relax the
requirement that [Ramp] be provided.  He asked EDA vendors to consider, what's
the worst that will happen if [Ramp] is completely bogus?  If there are newer
replacement keywords provided, should [Ramp] be optional?  If we continue to
maintain the [Ramp] requirement, we should add the missing parser checks
wherever possible.  He said we all agree that checking [External Model] vs.
[Ramp] is beyond the scope of the parser.  However, checks against all legacy
keywords, and even Ts4file, are theoretically things the parser could do.

Arpad asked whether we should have the parser check Ts4file vs. [Ramp] and the
I-V and V-t data.  Ambrish said he did not think so.  He said for Ts4file it is
made abundantly clear that the legacy keyword data should not be used.  Arpad
said he didn't disagree with that statement, but we had run into trouble with
early Ts4file models in which [Ramp] dt values had been set extremely low
because the model maker mistakenly thought [Ramp] was providing a stimulus
description.  Michael noted that the parser already checks and complains if
certain values are too large or too small according to some pre-defined sanity
check values.  For example, the parser complains about very large values in I-V
tables or large values of C_comp.  He said we might introduce a check against a
pre-defined threshold for dt.  Randy said that a hard low-limit sanity check
might work, but the parser can't test anything below that value.  Michael
suggested a message such as, "The Ramp dt seems too small.  It is intended to
describe the output's ramp rate".  The group noted that no one knew exactly
where the existing arbitrary thresholds had come from, perhaps the IBIS cookbook
discussions.

Michael said if we remove the requirement for [Ramp] when Ts4file exists, then
we don't have to worry about checking it.  Walter said we should keep the
requirement and add the same "first-order" language used in [External Model].
Ambrish said that [Ramp] is only "needed" when no V-t waveforms are provided.
We merely kept [Ramp] around in the early days for tools that didn't yet support
V-t waveforms.  Walter asked what problems occur if we just leave things alone.
He said we can add language saying that the parser doesn't check for consistency
in all cases.  Michael said the problem is the confusion caused by highly
inconsistent crosschecking.

Michael said that if we want to be consistent, we could either go with Ambrish's
approach and make [Ramp] optional and stop checking it at all when Ts4file or
[External Model] are present, or we can keep the [Ramp] requirement and be
better about the crosschecking.  Arpad said this went back to his previous
questions about whether we should introduce the additional crosschecks the
parser isn't currently providing.  He said he would prefer to see all the
reasonable crosschecking done.  Randy said that if we only check dV, and we
don't typically use dV, what's the point?  Walter said he had no objection to
adding dV and dt checks vs I-V and V-t data.  Randy said we might need to add
more info to [Ramp] to make all crosschecks against all waveforms possible.
Walter said even crosschecking against Ts4file wouldn't be difficult.  Michael
noted that some freeware might already have this implemented.  Michael took
an AR to reach out to one developer to see if they'd be willing and able to
provide code for this check.

Ambrish expressed concern that this is only getting complicated because we've
deviated from the original targeted approach for Ts4file, and we're now
envisioning a single [Model] containing all of these various keywords.

- Michael: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.

New ARs:

Yifan:  Draft a new version of BIRD220.1 including language describing the
        limitations of the approach.

Michael:  Check to see if see if Ts4file cross checking code could be donated
          for use by the ibischk parser.

-------------
Next meeting: 08 October 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
